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A grammar of plans is developed from a taxonomy of basic 
planning techniques. This grammar serves as the basis for the design of 
a new kind of interactive programming environment (SPADE), in which 
programs are generated by explicitly articulating planning decisions. 
The utility of this approach to program definition is that a record of 
these decisions, called the plan derivation, provides guidance for 
^ subsequent modification or debugging of the program. 

Moreover, this grammatical approach to planning allows the 
development of a taxonomy of bugs, as particular kinds of errors in 
applying the planning grammar. Following a linguistic analogy, five 
types of planning bugs are characterized: syntactic, semantic, 
pragmatic, circumlocutions, and slips of the tongue. The plan derivation 
can be accessed during subsequent debugging, to aid in diagnosing the 
underlying cause of erroneous code. Repair is accomplished via 
replanning, in which a substructure of the derivation is replaced. A 
debugging assistant for the SPADE environment (RAID) is designed based on 
this theory. 

The enterprise embodies Dijkstra's philosophy of programming in 
a structured fashion, but represents a more detailed study of planning 
and debugging techniques than has previously been attempted. 
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1. Introduction 



1.1. Background and Objectives 

Our goals in this report are: (1) to understand the processes by which a 
programmer, whether human or machine, moves from a declarative statement of a 
Ev°^!Vl a Pr ° Cedural stat ement of its solution; and (2) to discover methods 
by which these processes can be facilitated. We see programming as involving two 
Z I? I L 3C tivities: *«™*l»* and debugging. Host previous research has 
«*«i M T " tivitiM ln an isola t«d fashion. This report presents a 

unified theory of planning and debugging, based on a linguistic analogy. 

The investigation includes the design of an interactive programming 
environment called SPADE. SPADE is an acronym for Structured Planning and 
Debugging Editor. This name emphasizes two themes: (1) our perspective on 

SpAnpTL 3S a Pr ° CeSS ° f Planni " 9 and debu 99 in 9: and (2) our expectation that 
SPADE-like systems will eventually help in achieving the structured programming 
movement s goals of program reliability, readability, extensibility, portability 
and so on. The objectives for the SPADE programming environment are that ii 
serve, not only as a practical application of the theory, but also as an 
experimental crucible for testing claims of the theory.' 

In other papers the authors elaborate other dimensions of this linguistic 
approach to problem solving. [Miller & Goldstein 1976a] provides an overview of 
our research as a whole. [Goldstein & Miller 1976a] presents a long term 
research direction: applying the problem solving theory to the construction of a 

«, a , rn ,««l n , Vir ° nBent t0 t6aCh eleme "tary programming. In [Goldstein & 
Miller 1976b] the authors design PATN, an automated problem solver. In [Miller & 
Goldstein 1976b] the authors consider the use of grammars in the analysis of 
elementary programming protocols. In [Miller & Goldstein 1976d] the authors take 
steps toward automating this analysis task by designing a system called PAZATO. 

1.2. Overview 

The basis for SPADE's design is a unified problem solving theory which 
incorporates a fundamental linguistic analogy. The theory rests on a taxonomy of 
basic planning techniques. Planning, according to the theory, proceeds by a 
sequence of design decisions, in which the programmer selects a plan type and 
then carries out the subgoals defined by the application of that plan type to the 
current problem situation. This decision process is modeled by a context free 
grammar. 

This analysis of planning leads to a taxonomy of program bugs as well. 
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thIt C ci a a i r,' ha1 ;t he th60ry UnifUS Planning and debu 99ing i« based on the fact 
that classes of bugs are defined by tracing their origins to particular types of 

an r a i n o e g y US ttsfoT * "T"* "" ^^ "-"• Fo »- 4 - a 1 insist ic 
"'ii'' th f Se P lannl "9 bugs are characterized as: syntactic, semantic, 
pragmatic, circumlocutions, and slips of the tongue. 

ruip, ] h , e ^T SyStem WiU Pr ° Vide a " lnter Preter for context free grammar 
rtlnnina L" i Pr ° Vid \ bookkee P in 3 facilities, maintaining a record of the 
Hhh I " the application of "ch rule. This data structure 

generated by the grammar is called the plan derivation. Programs are merely the 
terminal strings of such derivations. Hence, SPADE should encourage programmers 

imnii ,A / .k P , Plannlng declsions ' "ther t^n merely leaving the plan 

implicit in the resulting code. 

The derivation structure created during planning episodes can be accessed 
during subsequent debugging episodes to aid in diagnosing the underlying cause of 
malfunctioning code. Repair would then proceed via replanning, in which a 
substructure of the plan derivation is replaced. One result of this repair would 
be that the purely hierarchical derivation tree is replaced by a cnart of 
alternative derivation trees. Diagnosis and repair techniques based on this 
theory are to be implemented in a debugging assistant called RAID (for RAtional 
Implementation of Debugging). RAID will be a component of the SPADE environment. 

«v«t.m T TK iS / a r r Presents the desi 9 n for SPADE. We plan to implement the 
system The implemented system will serve as the basis for a set of experiments 
exploring aspects of the theory, such as the relative effectiveness of 
alternative planning grammars. Examination of session transcripts coupled with 
systematic interviews of SPADE users will provide evidence for answering the 
following sorts of questions: 

1. Do users find the planning grammars adequate; or are there 
planning decisions which simply cannot be made given the 
restrictions of the grammar? 

2. How much of the grammar would remain the same in moving from 
one application to another? We initially plan to implement the 
domain dependent portion of the grammar for the Logo elementary 
graphics programming domain. 2 Later we intend experimenting with 
planning grammars for different domains, to include: the 
"blocks world," a set theory world, and an elementary calculator 
world. 

3. Do the plan derivation structures generated by the grammar 
serve as useful documentation, aiding one programmer in 
understanding and modifying programs written by another? 
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4. How effective is the system as a pedagogical alternative for 
teaching programming and problem solving? Can its effectiveness 
be attributed to such factors as greater articulation of 
planning and debugging strategies? 4 

flU ^t<„„ Th !/ nSWe JV° th6Se questions ' in turn ' w "l shed light upon a larger 
vaif'ti r S f' ^ the enterprise: does computational linguistics provide a 

problem solving? """^ ^ al9 ° rlthnS f0r ™"™^° ■ theory of 

Section two presents our theory of planning. The third section 
introduces the SPADE system. Our theory of debugging, and its embodiment in 

TilitJZ ♦ P \" ° f SeCUOnS f ° Ur and fiVe - We conclude b * discussing 

limitations, extensions, and applications to structured programming, automatic 
programming, and protocol analysis. 
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^ 2. A Gramm atical Theory of Planning 

. It would help a great deal if we had a general language 
specially designed for talking about Plans.... Such a language 
would, presumably, give us a convenient notation for such 
aspects as flexibility of Plans, the substitution of subplans 
conditional and preparatory subplans, etc. For example, it does 
not particularly matter in what order Mrs. Jones chooses to run 
her errands when she gets to town. The ... subplans can be 
permuted in order, and so we say that this part of her Plan is 
flexible. But she cannot permute the order of these with the 
subplan for driving to town, or for driving home. That part of 
the plan is inflexible. Some subplans are executed solely for 
the purpose of creating the conditions under which another 
subplan is relevant. Such preparatory or mobilizing subplans 
cannot be freely moved about with respect to the other subplans 
that they anticipate. Another important dimension of freedom 
that should be analyzed is the interchangeability of subplans. 
Mrs. Jones can drive to town over a variety of equivalent 
routes. The variety is limited only by the condition that they 
terminate when one of her three alternative destinations is 
reached, since only then would the next part of her Plan become 
r\ relevant. Given a satisfactory Plan and a statement of the 

flexibility and substitutability of its subplans, we should then 
be able to generate many alternative Plans that are also 
satisfactory. And we should like to have ways for deciding 

which combinations of Plans are most efficient 

[Miller et al. 1960] 

2.1. A Taxonomy of Plans 

olanninn LirH^ 6 « * ^"^ ° f Pla " S ' W begin Dy f °™lating a taxonomy of 

tl2ZT*T ? U 7 l Pr6SentS a taX0n ° Oy ° f a Variety of conmon Panning 

6 m 3 ^ thlS taXOn ° my Partly by i^rospection, partly by 

examining problem solving protocols [Miller & Goldstein 1976b], and partly by 

1967 1968 1" a TH Y T ° f Pr ° bl8m SOlVln9 Pr ° Vided by P ° lya C 1957 ' 196 *' I*™. 
diff^it ni' « T^ 1S lnc0B "> lete: Afferent domains would emphasize 

technlnr ' nni " 9 techni « Ues - 6 Yet the ™ *« certainly a core set of planning 
techniques common to all domains. 6 «»x"a 

The initial division in the taxonomy is into planning by identification 

SlTXXT. n a r d M y re h f °r ati ° n - The ^ "tegory "Ptures those me i 

which solve the problem by identifying it as one which is already known The 

O second provides guidelines for breaking the problem into pieces The third 
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I IDENTIFY- 



PRIMITIVE 



PREVIOUSLY DEFINED PROCEDURE 



-SET 



LLINEAR- 



— CONJUNCTION- 



PLAN 



DECOMPOSE- 



-NONLINEAR- 



-SEQUENTIAL 
-DECOMPOSITION 

-COMPOSITION 



— REPETITION- 



-ROUND 



--RECURSION 



l-REGROUP 



— EQUIVALENCE- 



REFORMULATE- 



'GENERIC <-> EXPLICIT 



-SPECIALIZE 



.SIMPLIFY. 



'GENERALIZE 
-ANALOGY 



FIGURE 1 
TAXONOMY OF PLANNING CONCEPTS 



/^"^ 



/"N 



Grammar Based Editor 7 Miller & Goldstein 

^hr ^^T thS - aU6mPt t0 reforraulate the Problem into a form more 
amenable to identification or decomposition. 

iwo J° r ^ any ,l 0main ' thePe are P rimitives and previously solved problems. 
Hence, the identification class breaks into these two sub-categories. Of course, 
there can be enormous subtlety in how a problem is recognized as an instance of a 
previously solved case. Constructing a taxonomy does not resolve this issue. In 
d«lf A "iHer 1976b] we introduce formal descriptions of the problem 

domain, and hence can address this issue more precisely. 

There are many decomposition techniques. The taxonomy of figure 1 cites 
only two: decomposition into conjunctive subgoals and decomposition into a 
single subgoal, repeated some number of times. Other decomposition techniques 
are appropriate for problems that can be decomposed into a disjunctive set of 
subgoals. or into a negation of some goal. Conjunction involves the critical 
question of whether each conjunct can be solved independently of the others, or 
whether there are interactions. Repetition divides into solution by simple 
iteration of a single subgoal or solution by full recursion. 

Reformulation is perhaps the subtlest of the planning categories. It 
includes finding an equivalent formulation of the problem which presumably is 
easier to solve or a critical simplification whose solution is a stepping stone 
to the solution of the original problem. Occasionally, one may even reformulate 
a problem into a stronger form: such as constructing an example when only an 
existence proof is required. 

How can we further explore this set of planning concepts? Our first step 
is to be more explicit about the decision process involved in selecting planning 
methods from this taxonomy. a 



2.2. A Planning Grammar 

We view planning as a process in which the problem solver selects the 
appropriate plan type and then carries out the subgoals defined by that plan 
applied to the current problem. 7 From this viewpoint, the planning taxonomy 
represents a decision tree of alternative plans. This decision process can be 
formalized by a context free grammar. 8 A grammar is chosen to present these rules 
because it provides a simple and compact representation, useful for 
characterizing the hierarchical structure of planning. We would not argue that a 
context free grammar is the appropriate formalism for representing a complete 
theory of problem solving - elsewhere we employ a more elaborate formalism. 
However, we believe that the grammar represents a useful abstraction of the 
decision points in the planning process. 
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^ The top level rule in the problem solving grammar is: 

PI: SOLVE -> plan + [DEBUG] 9 

The nonterminal SOLVE is formally analogous to the nonterminal SENTENCE in a 
linguistic grammar for parsing or generating sentences. PI states that planning 
is first used to generate a plan, with subsequent debugging then being required 
to complete the solution. Of course, the plan may be entirely correct. For this 
reason DEBUG is in brackets, indicating that it is an optional constituent. We 
snail have more to say about debugging in a later section. 

The planning taxonomy characterizes the planning process as involving 
three mutually exclusive plan categories: identification, decomposition, and 
reformulation. Hence, in planning, the problem solver must choose among these 
alternatives. We represent this by the disjunctive rule P2. 

P2: PLAN "> IDENTIFY | DECOMPOSE | REFORMULATE 

THo„,<r/°r, let US C ° nSider the deUilS ° f each of these Pining categories. 
Identification consisted of using a primitive or using a previously solved 
problem. This is described by P3. 

/-s p3 : IDENTIFY -> PRIMITIVE | DEFINED 

The firs* alternative leads to the use of primitives from the particular problem 
domain being investigated. 

The planning theory is modular, and independent of the application 
domain. But it is obviously critical to illustrate its applicability by concrete 
examples. In this report, we use the Logo elementary graphics programming domain 
as our source of examples. The task in this domain is to draw pictures with a 
cursor called the "turtle- by means of programs that move the cursor on the 
screen. Figure 2 illustrates the grammar rules for the primitives of this 
domain Figure 3 illustrates a typical goal undertaken by beginning programmers, 
a "wishingwell picture." 

The second identification alternative, DEFINED, involves retrieving a 
solution from the library of previously defined solutions and inserting it into 
the current solution. These two steps are captured by the rule P4. 

P4: DEFINED -> USE-CODE & GET-FILE 10 

We now turn to the second major planning category, decomposition Two 
important decomposition techniques are conjunctive plans, in which the problem is 
sub-divided into independent parts, and repetition plans, in which the problem is 
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Figure 2. Grammar Rules for Logo Primitive 



Ll. 


PRIMITIVE 


-> 


VECTOR | ROTATION | PEN 


L2. 


VECTOR 


-> 


FORWARDIBACK + "number" 


L3. 


ROTATION 


-> 


LEFT| RIGHT + "number" 


L4. 


PENSTATE 


-> 


PENUP | PENDOWN 



r^ 
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FIGURE 3 
WISHINGWELL PICTURE 
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characterized in terms of a sub-problem repeated some number of times. 
P5: DECOMPOSE -> CONJUNCTION | REPETITION 

nlLVV; ln " lude ° ther P lans "»r decomposing problems, such as disjunctive 
Plans, this rule would be extended by adding additional options. 

nomine,™ 6 JL" ??* Sh ° WS conjunction as splitting into two cases: linear and 

con linct.' r/n h T , C3Se 1S lnt6nded t0 rePreS6nt the SitUation wherein * he 
nrnhZ J„ h S V entirely inde P endent ly- The solution to the original 
problem then becomes simply sequencing the solutions to the subgoals- or in 

ZL^T' eXeCUting them in an * order - i-« ^e independence extends even to' the 
composition process. Solving for the roots of a factored polynomial is linear 
each root can be solved for independently) and the composition is set structured 
(the order of the solution does not matter). Solving for the sub-pictures of the 
wishmgwell shown earlier is independent, but to obtain the desired relations 
between the parts, some specific sequence must be established. Rule P6 defines 
the two cases for conjunction: 

P6: CONJUNCTION -> LINEAR | NONLINEAR 

Rule P7 specifies the two alternatives for a linear solution: 
P7: LINEAR -> SET | SEQ 

h« < P7is incomplete: The composition of independently solved subgoals might 

be in parallel, or via some interrupt control structure. A goal of our research 
is to develop the depth and breadth of the taxonomy and its associated procedural 
forms so as to include such constructs. 

A sequential plan consists of a sequence of actions, each consisting of a 
main step followed by an optional interface; these are preceded and followed by 
optional setup and cleanup steps. 

P8: SEQ -> [SETUP] + <MAINSTEP + [INTERFACE])* + [CLEANUP] 

The essence of a sequential plan is that the solutions to the main steps can be 
designed independently of each other. 

A set plan is simpler: the independence of the composition implies that 
no setup or cleanup steps are necessary. 

P9: SET -> <STEP>* 

For the programming domain, a setup, main step, interface, or cleanup 
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^ SOLVE 5 '' ° f 6ither th8 additi ° n ° f 8 Une ° f C ° dB ° r a recursiv ° application of 

P10: SETUP -> step 

Pll: MAINSTEP -> STEP 

P12: INTERFACE -> STEP 

P13: CLEANUP -> STEP 

P14: STEP -> ADD | SOLVE 

The grammar now admits potentially infinite recursion. What is not 
formalized by the context free grammar is the fact that SOLVE is always attempted 
with respect to some specific problem and in a definite context. Successful 
Planning involves solving successively simpler problems until a direct solution 
in terms of the answer library is possible. The semantic and pragmatic 
components, formalized in [Goldstein & Miller 1976b], would constrain the 
potentially infinite recursion allowed by the grammar. 

Similarly, the grammar does not capture the distinction between a setup, 
main step, and cleanup: they are all simply steps. There is, however, a 
semantic distinction. For example, the distinction between a main step and a 
setup depends on whether the code is designed to directly accomplish some subgoal 
-- a main step; or to establish some prerequisite for accomplishing some subgoal 
^ -- a setup. For example, in the Logo graphics domain, main steps generally 

involve drawing a visible part of the picture while setup steps have the goal of 
invisibly modifying the position or heading of the turtle between adjacent main 
steps. The Mycroft program [Goldstein 1974] included a program annotator that 
made such distinctions by comparing the picture drawn by the code with a 
predicate logic description of the intended picture." 

P15 states that repetition plans can be accomplished either by simple 
loops or by full recursion. (The latter is not elaborated here.) 

P15: REPETITION -> ROUND | RECURSION 

A round plan is the simple looping case, which can be accomplished either by 
iteration or by tail-recursion. (Tail-recursion is the restricted case wherein 
the recursion is constrained to be the last line of the program It is 
computationally equivalent to a simple loop structure.) The following rule 
captures this: 

P16: ROUND -> ITER-PLAN | TAIL-RECUR 

Figure 4 illustrates a triangle being accomplished by three different 

Logo programs. These correspond to the use of a sequential plan, a recursive 

f^ round plan and an iterative round plan. The annotations in parentheses, stating 
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TO TRI-SEQ 

FO 100 Main Step — (accomplish side one)- 



RT 120 -Interface Step-( P repare heading for side two)— 
FO 100 Main Step— (accompl ish side two) 



RT 120 -Interface Step-(prepare heading for side three)-" 
FD 100 Main Step (accomplish side three)— 



— Sequential 
Plan 



RT 120 -Cleanup Step— (accomplish heading transparency)- 
ENO 



(Tail Recursive Plan) 



TO TRI-REC 



FO 100 



! (no stop step: does not halt) ! 



in Step-( accompl ish side n)- 



dt ion » * . *-Seq Plan—. 

RT 120 -Interface Step-(prep. heading side n+l)-i 1 



TRI-REC 
ENO 



—Recursion Step- 



•— Tail 
- 1 Recursive 

Plan 



r\ 



(Iterative Plan) 



TO TRI-ITER 
REPEAT 3 — 



-Repeat Step- 



FO 100 -Main Step— (accompl i sh side n)- 



RT 120 —interface Step-(prep. heading side n+l)-J 
END 



1 I 
♦-Seq Plan— J 



"1 
•-Iterative 

Plan 
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what the planning step is intended to accomplish, are semantic descriptions not 
generated by the grammar. The grammar must be supplemented by semantic 
interpretation rules to allow for such analysis. 

Tail recursion may be represented as a sequential plan plus recursion and 
stop steps. Iteration is similar. 

P17: ITER-PLAN -> "repeat step" + SEQ 

P18: TAIL-REC -> STOP-STEP + SEQ + REC-STEP 

P19: REC-STEP -> "recursive program call" 

P20: STOP-STEP -> « st op program call" 

Reformulation, the third major planning category, should be briefly 
mentioned. Figure 5 provides a simple example of reformulation by regrouping the 
parts: a wishingwell, originally decomposed into a roof, a pole and a well is 
later viewed as decomposable into a tree and a well. Reformulation techniques 
depend intimately on the problem description. Hence, we do not consider them 
further in this report. The subset of the planning grammar employed here is 
summarized in figure 6. 



jf m \^ 
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Figure 5 

REFORMULATING THE WISHINGWELL IN TERMS OF A TREE 



TREE — 




WELL — 



-ROOF 



-POLE 




-WELL 



Since SPADE-0 has no problem description, it may not always 

BE APPARENT WHEN A REFORMULATION HAS OCCURRED, SOMETIMES IT 
WILL BE APPARENT, THOUGH, FROM THE DIALOGUE. FOR EXAMPLE: 

1a. What are your subgoals? 
1b. Roof, pole, well. 

2a. What would you like to do? 
2b. Redo choice 1. 

3a. Choice 1 undone. 

What are your subgoals? 
3b. Tree, well. 



/■"s 



4a. Rule for tree is: solve 
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Figure 6, 02: A Grammar of Plans 
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PI: SOLVE 
P2 : PLAN 
P3: IDENTIFY 
P4: DEFINED 
P5: DECOMPOSE 
P6: CONJUNCTION 
P7: LINEAR 
P8 : SEQ 
P9: SET 
P10: SETUP 
Pll: MAINSTEP 
P12: INTERFACE 
P13: CLEANUP 
P14: STEP 
P15: REPETITION 
P16: ROUND 
PI7: ITER-PLAN 
P18: TAIL-RECUR 
P19: REC-STEP 
P20: STOP-STEP 



-> PLAN + [DEBUG] 

-> IDENTIFY | DECOMPOSE | REFORMULATE 
-> PRIMITIVE | DEFINED 
-> USE-CODE & GET-FILE 
-> CONJUNCTION | REPETITION 
-> LINEAR | NONLINEAR 
-> SET | SEQ 

-> [SETUP] + <MAINSTEP + [INTERFACE]/ + [CLEANUP] 

-> <STEP>* 

-> STEP 

-> STEP 

-> STEP 

-> STEP 

-> ADD | SOLVE 

-> ROUND | RECURSION 

-> ITER-PLAN | TAIL-RECUR 

-> "repeat step" + SEQ 

-> STOP-STEP + SEQ + REC-STEP 

-> "recursive program call" 

-> "stop program call" 



/•""■v 
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^ 3. The SPADE Editor 

How can we validate a particular grammar? How can we judge whether the 
grammar captures at some level of abstraction the set of planning decisions 
involved in solving problems for some domain? One traditional methodology for AI 
is to develop an automated problem solving system. The grammar, however, is 
insufficient for this. Semantics and pragmatics are required to make our theory 
deterministic. (We develop this in [Goldstein & Miller 1976b].) 

But another methodology is possible. This involves incorporating the 
grammar into an intelligent editing system to augment the capabilities of the 
human problem solver. The critical question is whether such an intelligent 
support system successfully aids the user. In this section we design SPADE, an 
editor for defining programs that incorporates our planning grammar. 

3.1. SPADE-0: A Rudi mentary Planning Assistant. 

The name Structured Planning and Debugging Editor emphasizes the link 
between the problem solving theory being evolved here and the structured 
programming movement. Dahl, Dijkstra, and Hoare [1972] properly argue for 
^ programs that reflect coherently structured problem solving. But they do not 

develop a theory of planning in any great detail. Our effort in this direction, 
therefore, naturally supplements the examination of programming style initiated 
by Dijkstra and colleagues. 

Figures 7a and b illustrate an interaction with SPADE-0, our proposed 
grammar based editor. 12 The user is interested in defining a Logo program for 
drawing the wishingwell shown earlier. In the SPADE environment, this is done by 
applying the planning grammar in generative mode. The user begins by specifying 
whether the plan is to be an identification, decomposition or reformulation. The 
editor keeps track of the pending subgoals, allowing the user to move from one 
goal to another. 

Consider lines 6a and b of the SPADE-0 scenario. 

6a. Do you wish to include the optional constituent CLEANUP? 
6b. >LATER 

These lines illustrate the user suspending one subgoal, without completing it in 
order to pursue another. Although SPADE'S default is to suggest subgoals in -top 
down" order, the system will offer the user the freedom to deviate from this 
default, pursuing the set of required goals in any other order. The decision as 
^ to whether a CLEANUP step is needed in the sequential plan is part of the 
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Figure 7a. SPADE-0 Scenario (part a 



user', JLn„,T t\ T l ° n , ° f SPADE U Httle mre than ° bookkeeper for the 

user s subgoals. It is currently being implemented by assigning an interpretive 
procedure to each grammatical primitive. interpretive 

la. What is the name of your top level procedure? 
lb. >WW 

2a. Rule for WW is: SOLVE -> PLAN + [DEBUG]. 

Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 
What now? 
2b. DECOMPOSE 



3a. Rule for WW-4 is: 

What now? 
3b. SEQUENTIAL 



LINEAR -> SEQUENTIAL | SET. 



r\ 



4a, 



4b, 



Rule for WW-5 is: SEQ -> [SETUP] + <MAIN + [INTERFACE]^ + [CLEANUP] 

Do you wish to include the optional constituent SETUP? 
>No 



5a. How many occurrences of <MAIN + [INTERFACED do you want? 

5b. >3 

6a. Do you wish to include the optional constituent CLEANUP? 

6b. >LATER 



LATER is a command understood by SPADE. It means that the user wants to 
terminate this path, but that it must be recommenced later. SPADE keeps track of 

rlrZTlT f", ' :T Uding the U5er ° J the pendin9 * oal list */ <"***• Here it 
records the information required to return to, and eventually complete, the 

application of the SEQ rule. It can then go on to other goals. 
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Figure 7b. SPADE-0 Scenario (part h' 



7a. Your pending goals are POLE, ... and WELL. What NOW? 
7b. >POLE 

SPADE applies the SOLVE rule recursively. 

8a. Rule for POLE is: SOLVE -> PLAN + [DEBUG] 

Rule for POLE-1 is: IDENTIFY | DECOMPOSE | REFORMULATE. 
What now? 

8b. MDENTIFY 

9a. Rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 
9b. PRIMITIVE 

10a. Rule for POLE-3 is: PRIMITIVE -> VECTOR | ROTATION | PENSTATE 

What now? 
10b. >VECTOR 



/-\ 



>FORWARD 100 

11a. POLE completed. Pending goals are: ROOF, WELL, and WW- 17 (CLEANUP of 

WW). What now? 
lib. >WELL 



12a. Rule for WELL-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE. 

What now? 
12b. ^DECOMPOSE 

Here we have substituted a grammar which contains rules for conjunction but not 
repetition. This allows us to illustrate the manner in which SPADE avoids 
interrogating the user when no actual decision is reqvired. 

13a. Rule for WELL-4 is: DECOMPOSE -> CONJUNCTION. 
(Forced.) 

Rule for WELL-5 is: CONJUNCTION -> LINEAR | NONLINEAR 
What now? 
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^ CLEAMHp n ,hnTiH the , SU K Perprocedurs - <!»• Bo«l of deciding whether to f.cZ^e the 

CLEANUP should not be confused with the goal of designing the CLEANUP once the 
need for it has been established.) Some users might prefer to defer this 
decision until the main steps have been further elaborated. SPADE should be able 
to accomodate the alternative solution order. 

The typeout commencing at line 13a illustrates another feature of SPADE- 
o. (A similar sequence is shown at 2a.) 

13a. Rule for WELL-4 is: DECOMPOSE -> CONJUNCTION. 
(Forced.) 

Rule for WELL-5 is: CONJUNCTION -> LINEAR | NONLINEAR 
What now? 

Since the grammar is interpreted (rather than being "programmed in"), it is easy 
to tryout alternative grammars. Suppose, as is shown here, we employ a 
simplified grammar in which the REPETITION rules have been eliminated. (This 
might be useful in tutoring a novice for example.) Then no decision is actually 
required in applying the DECOMPOSITION rule. SPADE should notice this, and not 
interrogate the user in such cases. 

Figure 8 illustrates one possible derivation tree for WISHINGWELL as 
^ defined using SPADE-O. The utility of this record of the user's design decisions 

will become clearer when additional features of SPADE-0 are presented in the 
section on RAID. 

The implementation of SPADE-0 (which is now in progress) will not be 
difficult. It is simply a bookkeeping system for applying the planning grammar 
in generative mode to build a solution. The basic implementation technique is to 
provide an interpretive procedure for each grammatical operator (such as "|") 
Additional features can be implemented by assigning specialist procedures to non- 
terminals of the grammar, as will be done for the debugging assistance 
illustrated later. 



3.2. Towards SPADE- 1, and Bevond 

There is an upper bound on the utility of SPADE-0 which cannot be 
overcome by more careful human engineering. This is due to the fact that SPADE-0 
does not have access to a description of the problem being solved. When 
application of the grammar rules results in a recursive application of SOLVE 
SPADE-0 has no notion of the relationship of the subproblem to the top level 
SPADE 1 T ° ° VerCOne thiS fundamental Imitation, we intend to design and implement 
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SPADE l wnTh 6 9 s Sh r S 3 hypothetical interaction with SPADE-1. In many respects, 
SPADE- 1 will be similar to SPADE-0. It still is governed by a set of context free 

res a Zin r o rUl r' T d StiU Pr ° VideS »°^*^ facilities for spending and 6 
resuming subgoals However, SPADE-1 requests that the user supply a formal 

TZiJT th8 . Pr ° blen ' (A Ubrary ° f Standard probl - descriptions is 

howeJer w tho^ S. H d i lnB H l0CkS) ' THe US8r " €ed " 0t C ° mply Wlth th « r«n...t! 
however, without the problem description, SPADE-1 can help only as much as SPADE- 

assistanc^^ it TfiT ' eSCripti ° n ' SPADE " 1 would °* able to provide additional 

ih, Lw r T^ a Pr ° CedUre f ° r SOlVin9 a '""Problem already 

l,"^ 6 a " SWer llbrar ^ b * acce «ing the description of what that procedure 

«3ti.i e Vnf ""'I Perf ° rm rUdimentary ^positions, and perform more 
substantial inferences when the user bypasses intermediate steps. Coupled with a 

det e °r r m Tn nCe M nn ° tati0n m ° dUle (SUCh " ln Goldstein 1974]), SPADE-1 could 
spec^icauo^" "^ ""^ "'"" * 8lVM Sub >"cedure satisfies its 

The introduction of formal problem descriptions provides a first 
improvement over SPADE-0; introducing pragmatic constraints at choice points in 

forJiT'MT 1 ' T° Vide a SeCOnd ' ThiS l6adS t0 a more elaborate linguistic 
formalism which we briefly consider in the concluding section. 

While we plan to perform these extensions, from SPADE-0 to SPADE-1 and 
beyond SPADE-0 will still serve a useful role. The grammar based editor can 
support experiments on several important issues: (1) the adequacy of the 
planning grammar; (2) the domain independence of the planning grammar; (3) the 

.It \\ « , Planning 9 rannar i" terms of structured programming 

considerations; (4) the pedagogical value of an articulate planning environment 

There is another dimension along which the theory as presented so far is 
incomplete While the planning rules alone are sufficient to describe programs 
as static, finished objects, they do not capture the process of defining possible 
solutions, testing these solutions, and then debugging them. We need a theory of 
bugs and of their diagnosis and repair, to supplement our theory of plans. This 
is the purpose of the next two sections. 
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Figure 9. SPADE-1 Scenario 



With a description of the problem, SPADE could be more helpful. 

la. Tell me the name of your toplevel procedure' 
lb. >WW 

2a. Would you like to define a model? 
2b. >WISHINGWELL 

3a. OK. WISHINGWELL model found in Model Library. 

Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 

What now? 
3b. >ROOF POLE WELL 

4a * ™nVr^Dn« T a rJ!, T respond t0 model P arts - Are you pursuing a LINEAR 
DECOMPOSITION plan? 

4b. >YES 

5a. The pending subgoals are: ROOF, POLE, WELL and the decisions regarding 

inclusion of preparatory steps (WW-5) for WW. What now? 
5b. >ROOF 

6a. In the WW model, ROOF is described as a triangle. There is a TRIANGLE 
procedure in the answer library. Hence, an IDENTIFICATION plan may 
succeed. What now? 

6b. MDENTIFY 

7a. The TRIANGLE procedure in the answer library satisfies the intrinsic 

description of ROOF. Would you like to use it? 
7b. >YES 

8a. OK. The ROOF is complete. Your pending goals are POLE, WELL, and WW-5 

What now? 
8b. > 



9a. The first order goals for the parts are now complete. WW-5 (the choice 
of preparatory steps for WW) is complete. You have not expanded the 
definitions for the interface step, WW-6, nor for the cleanup step, WW- 
8. What now? 
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4. A Grammatical Theory of Debugging 

Bugs are so important that it is useful to classify them 
and give the classes names. In real world problem solving we 
often give names to important classes of bugs. In electrical 
engineering, for example, one class of bug is "instability." It 
may be manifest as "thermal runaway" or "spurious oscillation" 
in an amplifier. The underlying cause is "positive feedback," 
and there are several possible cures (patches) which may be 
applied: "negative feedback," or "isolation," for example. 

[Sussman, 1973, p. 170.] 

In earlier sections, we constructed a grammar of planning concepts and 
described programs as the terminal strings generated by this grammar. 
Unfortunately, problem solvers, whether human or machine, must often decide on a 
plan despite not only knowledge which is incomplete or uncertain, but also 
limitations on time and memory resources. The best of choices in such situations 
can turn out wrongly: debugging is then required. In this section, we follow 
Sussman's advice, developing a classification of bugs. Our goal in this 
classification scheme is to unify our approaches to planning and debugging by 
tracing the origin of bugs to various types of erroneous planning choices. In 
section five, we apply this perspective on possible planning errors to the design 
^ of a debugging assistant called RAID to be incorporated into the SPADE 

environment. 



4.1. Types of Bugs 

Given our perspective on planning, debugging can be analyzed as the 
localization and repair of errors in applying the grammar rules during 
generation. Since our planning rules were constructed from operators for 
conjunction, for disjunction and for optionality, there arise three basic classes 
of error: 

(1) syntactic bugs in which the planning grammar is violated, 
such as when a required conjunct is missing. 

(2) semantic bugs in which the plan is syntactically well-formed 
but some semantic constraint arising from the particular 
problem is violated, such as when a syntactically optional 
constituent, needed because of the semantics of the 
particular problem, is missing. 



/"" K > 



(3) pragmatic bugs in which an inappropriate selection from a 
set of mutually exclusive disjuncts is made. 
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This categorization is not complete: two other classes of bugs are 
circumlocutions- and "slips of the tongue.- 13 The first class represents plans 
which are successful but inefficient. The second class refers to miscellaneous 
errors in execution including mis-typings, mis-spellings and incorrect 
programming language syntax that do not reflect basic conceptual mistakes in the 
plan . 



4.2. Syntactic Planning Bugs 

When a decision made during a problem solving session violates the 
planning grammar, the resultant bug is termed syntactic."' An example of a 
syntactic bug is failure to include an obligatory conjunct. To illustrate this, 
consider the following error. In the solution of a problem, one subgoal matches 
a previously solved problem. Hence, the problem solver incorporates a call to 
the appropriate subroutine into the solution. But it is common to forget to load 
the file containing the subroutine into the current workspace. Figure 10 
illustrates this difficulty: as before, the goal is to write a program that 
draws a wishingwell. The roof is a triangle, which corresponds to a previously 
defined subprocedure. A call to TRIANGLE is placed in the WW procedure, but WW 
is executed before the file containing TRIANGLE is loaded. 15 

In terms of our planning grammar, this is a syntactic bug. The WW 
procedure is ungrammatical. The appropriate rule describing this situation is: 

P4: DEFINED -> USE-CODE & GET-FILE 

but the file retrieval is missing. 

Thus, syntactic bugs are those in which a necessary conjunct of a 
planning rule is not present in the plan. (Syntactic bugs might also be caused 
by the presence of an illegal extra constituent, but this class of problems seems 
less common.) Normally one would not expect a machine problem solver to make 
this kind of error, given a correct planning theory and no heuristic limitations 
However, resource limits on time or space might result in this performance.' 
Moreover, it is a common human error. 16 

The basic technique for repairing a syntactic bug (once isolated) is to 
redo the culpable planning decision in such a way that the grammar is no longer 
violated. For the case of a missing but obligatory conjunct, this implies 
solving for the constituent in question, and incorporating that solution into the 
larger solution at the required point. For the WW example in particular it 
means getting the TRIANGLE procedure from a file, and then reexecuting WW in' the 
corrected environment. 
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4.3. Semantic Planning Bugs 

violat e /th anti H *?* diff6r fr ° m Syntactic b "* s in ^.t no planning decision 
violates the underlying grammar; rather the usual case is that a constituent 

Ztl\t ° P r tl0 u nal in the graoinar is not Present, but is needed due to the 
semantics of the particular problem. This distinction can be understood more 
clearly by considering that syntax supplies broad constraints on the structure of 
solutions to all problems; semantics supplies additional constraints in terms of 
features of the particular problem at hand. Rules PI and P8 are typical rules in 
the grammar for which this kind of difficulty can arise: 

PI: SOLVE -> PLAN + [DEBUG] 

P8: SEQ -> [SETUP] + <MAINSTEP ♦ [INTERFACE])* ♦ [CLEANUP]. 

Debugging is necessary if the program produced during planning fails to 
accomplish its intended goals; otherwise, debugging is unnecessary. For a 
concrete example involving P8, let us return to the WW problem. Part of the 

SuToose th-t'Vh"" !! V"" tHe Wishin9 " e11 be drawn *» ^ upright position. 
PO.T h It th l° rder in which the **i" steps are executed is to be: ROOF. 
POLE, and then WELL. The subprocedure for the TRIANGLE expects the turtle to 
begin at a vertex, oriented along the circumference. Therefore, an initial SETUP 
(syntactically optional) rotation is required to vertically orient the 
wishingwell as a whole. Furthermore, additional interface steps are required to 
establish the required relationship between the ROOF and the POLE, that the POLE 
connect to the ROOF by intersecting with the center of its bottom side. Figure 
11 illustrates this local geometry, contrasting a semantically incomplete WW 
program to a corrected version. 

Since it is often an effective heuristic to design main steps before 
interfaces, one would not be surprised if a human programmer designed the 
subprocedures for the roof, pole and well, and then concatenated them, but forgot 
to include these necessary interfaces. Moreover, even for a machine problem 
solver, there are situations in which it would be more efficient (and therefore 
rational) to determine the need, if any, for such interface steps via trial 
execution and debugging, than via thorough but resource-intensive initial 
planning. 

In terms of the planning grammar, the overall plan for the WW is 
described as a sequential plan « that is, a sequence of main steps for the parts 
with optional interfaces. Given rule P8, the WW program illustrated by the 
previous figure is syntactically acceptable, but semantically incomplete. 

Semantic bugs can also occur when an optional constituent is present, but 
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DEBUGGING A SEMANTICALLY INCORRECT PLAN 
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/^ 
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semantically inappropriate. An example which we observed in a high school 
student was to always begin a procedure with the PENUP command, even when the 
first main step was to draw a visible vector. This resulted in either: (a) when 
the program was first run, the first vector would be missing, and then the PENUP 
would be deleted by a debugging edit; or (b) a PENDOWN command would be added to 
the procedure: inefficient but otherwise harmless extra steps. 

The general repair strategy for semantic bugs is to redo the culpable 
Planning decision in such a way as to satisfy the violated semantic constraints. 
In particular the repair for a semantically incomplete plan is to solve for the 
missing conjuncts and incorporate them into the solution as a whole. For the 
wishingwell, this involves designing setup and interface steps, and then editing 
the WW superprocedure to employ them. 

4.4. Pragmatic Planning Bugs 

Some grammar rules describe alternative strategies to accomplish a given 
Plan. Formally these appear as mutually exclusive disjuncts. Examples include: 



P2 
P3 
P6 



PLAN "> IDENTIFY | DECOMPOSE | REFORMULATE 

IDENTIFY -> PRIMITIVE | DEFINED 

CONJUNCTION -> LINEAR | NONLINEAR 



P15: REPETITION -> ROUND | RECURSION 

Pragmatic bugs are those in which an incorrect disjunct is chosen. 

As an illustration, consider grammar rule P6 for conjunctive plans. It 
specifies two alternatives for accomplishing a set of subgoals: a linear and a 
nonlinear strategy. Now in this case, the formal roles played by the alternative 
disjuncts are syntactically indistinguishable with respect to the overall 
grammar. The pragmatic difference, which is not formalized here, is that a 
linear decomposition solves for the sub-problems independently while a nonlinear 
decomposition solves for some subgoals given knowledge of other subgoals. 

In general, linear plans are simpler to apply because of their 
independence assumption. However, pragmatic bugs arise when the planner is faced 
with a type of problem in which there are inherent interactions between the 
steps. An example of where linear problem solving is inadequate in the graphics 
world is the apparently simple task of drawing a square inside a triangle (figure 
12). Suppose a linear plan is pursued. This gives rise to two main steps (the 
square and the triangle), and an interface step. If the main steps are solved 
independently of one another (by means of SQUARE and TRIANGLE subprocedures) it 

i S y^™™* the fl9UreS produced wil1 be of the w ""9 size to permit 'the 
desired INSIDE relation to hold. This violation cannot be corrected by altering 
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Figure 12 
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the order of composition; nor can it be repaired by modifying the interface. 
The bug is pragmatic, in that neither syntax nor semantics are violated, but the 
choice of the linear over the nonlinear disjunct nevertheless leads to an 
unsuccessful plan. 

^ P ^ a9matiC bU9 1S repaired ^ redoin 3 the culpable planning decision so 
as to satisfy the violated pragmatic constraint. (It may be that the problem 
solver was ignorant of the relevant constraint prior to solving the current 
problem This brings up the matter of skill acquisition which is deferred till 
the concluding section.) In the SQUARE-WITHIN-TRIANGLE problem, violation of the 
predicate INSIDE is repaired by changing to a non-linear plan. The second main 
step to be solved must be designed in the context of a particular size decision 
tor the first main step. For example, the specification for TRIANGLE is changed 
to require that its side be larger than a constant which is determined by the 
side length of SQUARE. 

4.5. "Circum locutions" (Inefficiency Bug s) 

A procedure which solves its specified problem, but in a roundabout 
"J"" 6 ;; is "" t0 have a "circumlocution" or an inefficiency bug. Such 
inefficiencies can occur in plans where a non-optimal disjunct is chosen or an 
^ unnecessary (but harmless) optional constituent is included. Correcting 

inefficiencies is the typical concern of compiler theory and we do not address it 
here, except to make the point that the hierarchical annotation (or derivation) 
generated by the grammar is conceivably a useful description for a compiler to 
access. 

, ~„ , T ° illustrate this ' consider rational form violations, the subclass of 
inefficiencies due to local oddities in the code, such as sequential invocations 
of a given primitive. 17 This class of inefficiencies has been extensively 
investigated m the literature on optimizing compilers. However, it is possible 
that such a rational form violation is due to some serious omission in the 
program; i.e., it is a warning that a bug may exist [Goldstein 1974]. 

IZitlT f°l Pilers have no basis for a Judgment, but access to the planning 
derivation of the program can often illuminate this issue. 

For example, one of the ways in which such an inefficiency bug can arise 

ll !TV "k" ° f a " "^'i "^" P lan C Mil ler 1976]. Although the grammar 
provided in this paper does not attempt to formalize this type of plan, basic 
evolutionary plans are not complex. The programmer attempts to alter the code of 
a previous program to achieve the specifications of a new, but similar, problem. 
To illustrate such a situation, however, we must develop a somewhat elaborate 
example. Please reexamine figure 5. A wishingwell, initially viewed as 
^ involving three subproblems, has been reformulated so as to involve two main 
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steps, the TREE and the WELL. The TREE program is state transparent: it leaves 
the turtle in the same state in which it started, at the bottom of its TRUNK 
(which serves as the POLE of WW). WW incorporates a nonlinearity for efficiency 
the top side of the WELL is accomplished in two parts, to avoid retracing 
previous vectors. 18 Suppose that the programmer needs a SQUARE subprocedure for 
use in another project. One strategy is to adapt WW by deleting the call to TREE 
(figure 13). After this deletion, though, the resulting SQUARE contains 
sequential calls to FORWARD: a rational form violation. The optimization is to 
combine these two invocations into a single call to the FORWARD primitive. 

Thus, a compiler could first check whether an evolutionary plan governs 
the inefficiency. If so, it could perform the optimization with some confidence. 
IT not, it should notify the programmer of the oddity in the code. 

4.6. "Sli ps of the Tongue" (Execution Errors) 

A final category of bugs is necessary when human programming protocols 
are to be analyzed. This class, "slips of the tongue," is a catch-all for 
typographical errors, confusions due to orthographic similarity, incorrect 
programming language syntax, noise on the computer line, and other failures to 
successfully type in a statement of code. They are often diagnosed by 
^ conventional computing environments, simply as a result of the code being 

unrecognizable. The plan is not affected. We include this class for 
completeness, so that our discussions may span the space of possible bugs. The 
planning grammar does not provide an explanation for the origins of these bugs. 19 

The general repair technique for slips of the tongue is to: (a) undo the 
side effects, if any, of the incorrect type-in; and (b) reexecute the type-in 
correctly in the restored environment. This could be captured by a rule such as: 

REPAIR -> [UNDO] + REDO 

A common error in debugging technique is to compound an initial "slip of the 
tongue error" by reexecuting, without undoing undesirable side effects. 20 

Having a classification of basic bug types does not solve the debugging 
problem: it is only a starting point. The next step is to develop a theory of 
diagnosis and repair, by which the underlying bug made manifest by an 
unsuccessful program run can be diagnosed, and then repair knowledge associated 

!k o? 1S 9 tyPG "" be aPPUed t0 COrreCt the P r °9 rara - 5e ^ion five designs 
the RAID assistant that will monitor a programmer during the planning of a 
procedure and generate caveats regarding possible errors for aid in subsequent 
debugging. This monitoring will happen within the SPADE editing environment 



Grammar Based Editor 



Miller & Goldstein 



/-\ 



Figure 13 

DEBUGGING A CIRCUMLOCUTION OR INEFFICIENT PLAN 
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70 FORWARD 100 
80 RIGHT 90 
90 FORWARD 100 
END 



\ EVOLUTIONARY PLAN 



TO SOUARE-1 
5 RIGHT 90 
10 FORWARD 50 
30 FORWARD 50 
40 RIGHT 90 



STARTS HERE J 
ENDS HERE £ 




>TREE 



} RATIONAL FORM VIOLATION 



STARTS HERET 
ENDS HERE ^ 



SQUARE-1 




END 



\ CAVEAT DRIVEN DEBUGGING 



TO SQUARE-2 
5 RIGHT 90 
10 FORWARD 100 
40 RIGHT 90 



END 
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Figure 14. A Surface Grammar For Debugging 



DEBUG 

DIAGNOSE 

TRACE 

SELF-DOC 

ASK 

REPAIR 

ADD- PAUSE 

ADD-PRINT 

ADD-TRACE 

EDIT 

RUN 

ADD 

DELETE 

CHANGE 



-> <[DIAGN0SE] + [REPAIR]/ 

-> <ASK | TRACE | "error">* 

-> [SELF-DOC*] + RUN* 

-> ADD-PAUSE | ADD-PRINT | ADD-TRACE 

-> "print definition" | "print value" pprint file"| 

-> <RUN | EDIT | S0LVE>* 

-> ADD 

-> ADD 

-> ADD 

-> ADD | DELETE | CHANGE 

-> "run statement of code" + "response" + [DEBUG] 

-> "add statement of code" + "response" + [DEBUG] 

-> "delete statement of code" + "response" + [DEBUG] 

-> "change statement of code" + "response" + [DEBUG] 



/00**S, 



*"\ 
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FIGURE 15 - A TAXONOMY OF DEBUGGING TECHNIQUES 



DEBUG ■ 



.PARSE ADVISE (planning choices) 



' DIAGNOSE- 



-CODE • 



-PRINTOUT 



-ADVISE (rational form* violations) 



•MODEL ADVISE (model violations) 



L 



PROCESS- 



-ASK 



TRACE 



■DO 



REPAIR- 



•COMPLETE 



CORRECT 
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5. The RAID Debugging Assistant 

Let us focus on one particular component of [general heuristic 
knowledge]: the art and techniques of . . . debugging. The 
school experience is dominated by the normative attitude implied 
by "right answer vs. wrong answer". The mathematician's 
experience of mathematics is dominated by the purposeful- 
constructive attitude implied by the struggle to "make it work". 
He abandons an idea not because it happened to go wrong, but 
because he has understood that it is unfixable. Dwelling on 
what went wrong becomes a source of power rather than a piece of 
masochism (as it would appear to most fifth graders in 
traditional math classes). 

[Papert, 1973, p. 10] 

5.1. Diagnosis and Repair 

We have now developed a taxonomy of bug types -- of what use is it? Its 
first use, we believe, is that it clarifies our understanding of debugging by 
identifying major categories of error. Secondly, it suggests how to design 
better debugging aids for the programmer and problem solver. In this section we 
develop this position by designing the RAID component of the SPADE program 
editor. RAID is an acronym for RAtional Implementation of Debugging, stressing 
our belief that debugging is often a consequence of heuristically Justifiable 
problem solving, not an embarrassment indicative of irrational or "sloppy- 
thinking. RAID is a tool designed to make debugging a source of power to the 
problem solver, as Papert suggests it can be. 

Let us consider further how the taxonomy clarifies our understanding of 
debugging. A programmer's approach to debugging is, naturally, colored by the 
diagnostic tools provided by the particular computer system. However, the 
facilities provided by a wide range of computing environments have much in 
common. These tools manifest what we term surface debugging techniques. They 
are based on examination of the code and snapshots of the computational process 
elicited by the code, both relatively superficial descriptions of the procedure 
as conceived by the programmer. Figure 14 shows a grammar which partially 
formalizes this surface debugging activity. 

Access to the problem description and -- most importantly -- the 
programmer's plan allows for a deeper analysis of debugging strategies 
Figure 15 shows a taxonomy of these debugging strategies. Figure 16 shows how 
this taxonomy is transformed into what we term a deep debugging grammar, for 
contrast with the previous grammar. Notice that examination of the plan plays an 
important role. 
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Figure 17. RAID Advice f or Syntactically Incomplete Planning Bugs 

la. Which subgoal would you like to pursue? 
lb. >POLE 

2a. Rule for POLE-1 is: PLAN -> IDENTIFY j DECOMPOSE | REFORMULATE. 

What now? 
2b. MDENTIFY 

3a. Rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 
3b. >LATER. 

The LATER command causes further processing of this subgoal to be postponed. 
RAID, the debugging component, creates a caveat each time a LATER command occurs. 
The caveat records the fact that this part of the plan is syntactically 
incomplete at this point. 

4a. POLE-2 postponed. Your pending goal list contains the remaining subgoal 

WELL. Which goal would like to pursue? 
4b. >WELL 



5a. We have now completed the WELL subgoal. What now? 
5b. >RUN WISHINGWELL 

The caveat recorded earlier is a "demon," triggered by premature execution of the 
procedure being designed. If this occurs, the function of the caveat is to 
remind the user of the syntactic incorrectness of the program. 

6a. Running WISHINGWELL at this time results in the bug manifestation: 
UNDEFINED PROCEDURE: POLE. 
This is because WISHINGWELL is syntactically incomplete: it contains 
the pending subgoal POLE-2. The recommended repair technique is to 
complete the solution of the subgoal POLE-2. Would you like to work on 
POLE-2? 

6b. >Yes. 

7a. You were solving POLE via an IDENTIFICATION plan. You postponed the 
decision (POLE-2) as to which answer library to use. 
The rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 
What now? 
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Figure 16. A Deep Grammar For Debugging 



DEBUG -> <[ DIAGNOSE ] + [REPAIR]/ 



DIAGNOSE -> <PARSE | CODE | MODEL | PROCESS^ 



PROCESS -> ASK | TRACE | DO 



CODE -> PRINTOUT | "advise rational form violations" 



MODEL -> "advise model violations" 



PARSE -> "advise heuristic planning choices" 



REPAIR -> COMPLETE | CORRECT 



COMPLETE -> "solve for missing conjunct" 



CORRECT -> "choose alternative disjunct" 



f^ 
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In the SPADE system, the end product of the interaction is not merely a 
program, but a program annotated by its associated plan derivation (please refer 
to figure 8 presented earlier). The reader has undoubtedly noted that far more 
interaction would be necessary with SPADE, than with an ordinary editor. 21 In 
return for this extra planning effort, there are several potential benefits. The 
first is that by knowing the plan, the RAID component of SPADE would generate 
caveats regarding possible bugs for aid in subsequent debugging. Since 
definition of the program generally occupies far less time than debugging, some 
additional effort in planning may well be worthwhile in terms of more efficient 
debugging. It is also possible that articulating the plan serves to improve a 
student's planning skills. 22 Finally, the plan as commentary should make the 
resulting code far more understandable to other programmers who, in large 
projects, may be expected to modify or debug the package. We have yet to 
consider "human-engineering" aspects in designing SPADE/RAID, nor have we begun 
to experiment with it. Here, our goal is only to describe those parts of the 
RAID debugging assistant that are predicated on our taxonomy of bug types. 

5.2. Aid In Diagnosing Syntactic Bugs 

SPADE provides the facility of being able to suspend the construction of 
^ a solution of one sub-problem in order to analyze other goals. This is useful, 

since occasionally insight into the solution of other goals is helpful for 
completing the current problem. SPADE provides bookkeeping facilities for this 
suspension. The goal can be resumed later. To illustrate this, we shall refer 
to figure 17. Line 3b shows the user choosing to postpone a goal. 

3a. Rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

What now? 
3b. >LATER. 

RAID, the debugging component, would create a caveat each time this 
happens. The caveat would record the fact that the plan is syntactically 
incomplete at this point. A caveat is a demon, which would triggered by 
premature execution of the procedure being designed. If this occurs, the 
function of the caveat would be to remind the user of the syntactic incorrectness 
of the program. 

5b. >RUN WISHINGWELL 

6a. Running WISHINGWELL at this time results in the bug manifestation: 
UNDEFINED PROCEDURE POLE. 
^ This is because WISHINGWELL is syntactically incomplete: it contains 

the pending subgoal POLE-2. The recommended repair technique is to 
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complete the solution of the subgoal POLE-2. Would you like to work on 
' POLE-2? 

Line 6a in the figure illustrates this. 



5.3. Aid in Diagnosing Semantic Bug s 

Whenever an optional constituent is rejected, RAID would create a caveat 
to the effect that the plan may be semantically incorrect at this point. When 
the program subsequently is executed and bugs occur, the programmer could request 
aid. This aid would include a description of which planning decisions are 
possible semantic errors. This sort of interaction with SPADE is illustrated by 
figure 18. 

Line lb shows the programmer choosing to dispense with an optional 
interface step. 

la. Is there an INTERFACE following WELL? 
lb. >N0 

When the program is subsequently tested at line 2b, the programmer is not 
satisfied with the results. 

4b. >ADVISE-PLAN 

5a. WELL may be semantically incomplete. Perhaps an INTERFACE is needed 
after WELL. Would you like to reconsider, and include such a step? 

RAID is then depicted pointing out that the decision to not include an optional 
interface may be the culprit (line 5a). 



5.4. Aid in Diagnosing Pragmatic Bugs 

Certain alternative planning methods have the relationship that one 
method is simpler but subject to failure in some cases, while the other is more 
complex but more powerful. Examples are LINEAR versus NONLINEAR plans and ROUND 
versus RECURSIVE plans. Whenever the user applies the simpler of one of these 
pairs, RAID creates a caveat to the effect that a commitment to a possibly 
incorrect plan has been made. This caveat serves the same purpose as those 
created above for possible semantic bugs. Upon subsequent execution, if the user 
is unhappy with the results, aid can be requested. The caveat then points out 
possible pragmatic errors. 
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Figure 18. RAID Advi ce For Semantically Incomplete Planning Bugs 



la. Is there an INTERFACE following WELL? 
lb. >NO 

Whenever an optional constituent is rejected, the RAID debugging component 
creates a caveat to the effect that the plan may be semantically incomplete at 
this point. 



2a. We have now completed subgoal WELL. 
2b. >RUN WISHINGWELL 



What now? 



When the program subsequently is executed and bugs occur, the programmer can 
request aid. This aid includes a description of which planning decisions are 
possible semantic errors. In this case, the WW procedure produces a picture 
which does not satisfy the VISHINCWELL model. While SPADE-0 can aid in plan 
diagnosis, it cannot detect model violations without user input. (SPADE-1, 
however, would perform model diagnosis.) 

3a. OK. What now? 
3b. >DIAGNOSE 



4a. Rule is: 

DIAGNOSE - 
What now? 

4b. >ADVISE-PLAN 



> ADVISE-PLAN | ADVISE-CODE | ADVISE-MODEL | ADVISE-PROCESS. 



5a. WELL may be semantically incomplete. Perhaps an INTERFACE is needed 

after WELL. Would you like to reconsider, and include such a step? 
Ob • /YES 



6a. Solving for WELL-13 (INTERFACE after WELL). 
Rule is: SOLVE -> ... 



/■^ 



r\ 
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Figure 19 illustrates this kind of interaction with SPADE. 
5b. >ADVISE-PLAN 

6a. In designing SQUARE-WITHIN-TRIANGLE-3, you opted for a LINEAR 
decomposition. It is possible that this problem involves some 
interaction between TRIANGLE and SQUARE. Do you wish to reconsider 
your previous decision, and try a NONLINEAR decomposition? 

n^LV n , the . fl9Ure Sh ° WS the "*" con » onent acting the user to a possible 
pragmatic planning bug. 



5.5. Assistance in Repair 

, ntt ,« , ^ ? Sten ° 0Uld d ° m ° re than just alert tne user to the problem. It 
rZJt r S l, } PetUrn tHe "^ t0 the suspended W«l. and (b) inform the user, by 
means of the grammar, of what alternative constituents are available. Line 7a of 

Isy^tactic bur"' 6 " 6arller) 1UUStrateS this repair assistance for the case of 

7a. You were solving POLE via an IDENTIFICATION PLAN. You postponed the 
decision (POLE-2) as to which answer library to use. 
The rule for POLE-2 is: IDENTIFY -> PRIMITIVE | DEFINED. 

Suppose the user decides to undo a given planning decision, perhaps 
abandoning a very detailed plan which resulted from considerable effort, in favor 
of a new approach. It is possible that later the user may reconsider, and wish 
to reactivate the abandoned approach. It would be rather unfortunate if RAID had 

Trill r h IT " 65 . ° f US 6Xlstence - In fa <t. it would not. In order to keep 
track of both active and hung alternative versions of each planning decision 
however, the derivation tree representation ceases to be adequate. A more 
elaborate data structure is required; SPADE/RAID would use a cAart for this 
rZTll'7, ^ , Ch VJ? a StrUCtUre W9S lntroduced in computational linguistics 
substring «7 *V°< eC ° n0miCally Store a record ■' alternative well-formed 

substrings discovered during sentence parsing. We introduce the chart here for 

Tall \\ n re rT 0nS \ n r^ 6 ° f SUCh 3 Ch3rt aPPlied t0 the Pining context is 
shown in figure 20; figure 21 shows a user taking advantage of this capability. 

The chart data structure provides benefits which feed back into the 
llZl -" a : SiStant aS Wel1 ' For exa n»Ple, with the chart one can distinguish 
between using a cop, of a previous subprocedure "in line,- versus using the 
previous subprocedure as a "black box" which is invoked: 



t^\ 
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Figure 19. RAID Advic e Fo r P ragmatically Tncorrect Planning R,,^ 



la. Rule for SQUARE -WITHIN-TRIANGLE-1 is: 

PLAN -> IDENTIFY | DECOMPOSE 
What now? 
lb. >CONJ 



REFORMULATE 



2a. I have assumed DECOMPOSE -> CONJUNCTION. 

Rule for SQUARE-WITHIN-TRIANGLE-3 is: 

CONJUNCTION -> LINEAR | NON-LINEAR. 

What now? 
2b. >LINEAR 

simllll l l l ern l tiVe . Pla " ning metk ° dS haV& the rela ^onshi P that one method is 
simpler but subject to failure in some cases, while the other is more complex but 

TecIAZ^ 1 - Ex T es are LmM uersus mLmAR "■" «■' «o7n\eZs ex 

RArn JZ * e " er ** e U5er aPplies the simpler °f °" e of these pairs. 

nlin " ° °T at t0 thG effeCt Uat ° "»«**««"« to a possibly incorrect 

plan has been made. 

3a. Rule is . . . 
3b. > 



4a. We have now completed SQUARE-WITHIN-TRIANGLE 
4b. >RUN SQUARE-WITHIN-TRIANGLE 



What now? 



r^ltfw eqr "rf e * eCUtlon ' if the us *ris unhappy with the results, aid can be 
WUAHE-WITHIN-TRIANGLE procedure draws the picture "inside out." 



5a. Rule is: 

DIAGNOSE -> ADVISE-PLAN | ADVISE-CODE 
What now? 
5b. >ADVISE-PLAN 



ADVISE-MODEL | ADVISE-PROCESS. 



6a. In designing SQUARE-WITHIN-TRIANGLE-3, you opted for a LINEAR 

decomposition. It is possible that this problem involves some 
interaction between TRIANGLE and SQUARE. Do you wish to reconsider 
your previous decision, and try a NONLINEAR decomposition? 

ob. >YES 



/"> 



7a. What non-linear constraint(s) do you wish to add to the SQUARE? 

* U • x 
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Figure 21. Returning to a Previously Hung Plan 

la. Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE | REFORMULATE 

What now? 
lb. ^DECOMPOSE 



2a. What are your subgoals? 
2b. >ROOF POLE WELL 



3a. Rule for POLE-3 

What now? 
3b. >REDO WW-1 



is: IDENTIFY -> PRIMITIVE | DEFINED 



f~\ 



Considerable planning effort has been invested in the current version of VW-1 
The system should be able to record the state of the work so far in case it is 
ever needed again. It might seem too co*tI|f. though, to save away multiple 
copies of the plan derivation every time a choice is redone... 



4a. Previous choice on WW-1 undone. 

Rule for WW-1 is: PLAN -> IDENTIFY | DECOMPOSE 

What now? 
4b. REFORMULATE 



REFORMULATE 



5a. What are your subgoals? 
5b. >TREE WELL 



/-s 



6a. Rule is: SEQ -> [SETUP] + <MAINSTEP + [INTERFACE]^ + [CLEANUP! 

What now? 
6b. >REDO WW-1 

At this point, the user has decided to return to the previous approach findina 
that the REFORMULATION has resulted in an even harder problem. SPADE'S chart 
representation for plan derivations in fact allows prior versions to be saved 
without incurring overwhelming storage costs. 

7a. A previously hung version of WW-1 (WW-1:V1) exists, involving a 

DECOMPOSITION plan. Do you wish to reactivate it? 
7b. >YES 



8a. 



When WW-1.-V1 was hung, your current goal was POLE-3 
Rule for POLE-3 is: ... 



r*\ 
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P4': DEFINED -> COPY-CODE | CALL-CODE & GET-FILE 

The revised rule P4« has the virtue that one can specify whether future 

;;;:: to If * e h ^?» • ub ^- to shouid *"*« *• proddur.^ y ' lilZ 

ZinJ' t «. \ ° DE dlSJUnCt iS Ch ° Sen ' the chart wil1 contain only a 

a o benefit th ^ T^"'' future lavements in the subprocedure win 
n^nt? T ♦ V ° procedure ' Conversely, future changes could introduce 

arllLti P V PertUrbati0ns ' This ind ^ates how the insights gained from a 

veHnnth 3PPr0a i Ch t0 Pr ° blem SOlVin9 Can lead t0 f o-ali Z ing the origins of 
yet another commonly observed source of program bugs. 



/■> 
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6. Conclusions 

6.1. Limi tations and Extensions 

mt.in TH ! Ul , timate version of SPADE ou 3ht to include a module for providino 
inte ligent planning advice and filling in low level details of partiaUy 
specified solutions. However, a context free grammar, being inherently non 
deterministic, would not suffice as the basis for a machine p^oblS .olw" 

sou Jon" IT: 5 9enerating aU P ° SSible Ovations and then testing for a 
solution would hardly be practical. 

skill a! h ,nZt S alS °/ the ° retical de ^^«ncy. There ought to be a facility for 
^/tr^tW- r SUnmariZlng PreVi0US semantic or pragmatic planning 
mmMH* I I r6CUrrence on similar Proble.. in the future. Such a 

context fr" S 'I 6 ' ^ SUSSnan ' S C19733 MCKER Pr °^ for «»-Pl«. But our 

that stantl ^^ *", "° ^ ° f representin 9 repair knowledge in such a way 
that semantic or pragmatic bugs are not repeated. 



fr „ ni . B ° th ° f these de f^iencies can be addressed by moving from the context 

netw\ r 9 rrw7o r ds re i P 9 r 7 e ni ent f i0n ^ Planni " 9 kn ° Wledge t0 a " aUgraented transition 
arlr»-r 3 ' AUgmented transition networks generalize the context free 

grammar representation. To see the way the ATM serves as a natural 

eau^l ^ " ° f thG 9rammar> flrSt 6Xamine fi ^ 22 ' Here we have aJ 
^r.iJT tr3« 6nta ?\ fW tHe ° 2 PlanninS 9rammar 3S a ("-augmented) 

generalLation^ • m ""T^" ^ '^"^ tranSiU ° n n6tW ° rk provides — 
generalizations: (1) registers can be provided to store the values of variables- 

«d (3 actTonTc^ T^' """ ""* <° C °" tr01 the ^ ° f transition;' 
tran.it Z ""elated with arcs to build structures during 

TovercZ 5 ; n?"?™™?**"™ ™* introduced in computational linguistics 
have It in ti "Jr ° f tHe CFG represe "tation that parallel those that we 
02 Some 1 ,,7 ^Y^ 1 " 9 realn »' Fi S-« 23 is the planning ATM based on 
G2 Some (not all) of the registers, conditions, and actions (for storing and 

are tereffi i"' ™" 00 ab0Ut the — t sub-problem) are shown. Not e how 
greater efficiency can be achieved via techniques such as collapsing states -- 
moving some information from the topological configuration to the registers 
(e.g the CONJUNCTION and SEQ+SET nodes). Figure 24 shows how arc predicates 
can be used to select the appropriate plan type on the basis of features of the 
problem description. This approach (called PAW, for Planning An) is developed 
at length in [Goldstein & Miller 1976b]. Here our goal is only to show how 
in'an ATN """ "' "^ » WADE/RA1D * ""•"»«.* plan ing ° ^^ 



r^. 



«.-« C °» Sid , e , r a9ain the S( 3 UARE - W "HIN-TRIANGLE problem discussed in the RAID 
section. Recall that the underlying cause of the bug was treating the SQUADS 
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rs co^traL'Tthai" lf ""' "" i " dap8 " d8 " t - '« f«t. a second order 

th», s P ec ifically, this is done as follows: figure 25 shows that part of PATH 

that corresponds to the rule, 

P6: CONJUNCTION -> LINEAR | NONLINEAR. 

wnM,T d ^?n Ult aPC ° rderins causes th « LINEAR plan to be attempted first The 
NONL NEAR transition is allowed only if the NLC or NLD predicates recognize The 

Ttaken"^^ 1 I, 3 n "" llnMr1 "- Here « " "»"* i« Present, the NLD 1 
is taken and the problem description modified to make the interaction explicit 

constr\i P n r t N C rn e tM: T n a p dded t0 «" deSCription ° f «■• parts. Thus, a new arc 

error 7™ h NLD \ IN,SIDE ' ServeS to prevent th i* Particular pragmatic planning 
error from happening again. y 

6.2. Applications 

^ thr.. Th ! S6 idGaS l6nd themselves t0 a var iety of applications. We consider 

programming programinin 9' automatic protocol analysis, and structured 

As semantic and pragmatic capabilities are added to SPADE (reflected by 

TrltZTTV °, f PA ™ ^ Pr ° Vldin9 3dViCe) ' the user would ^ consulted on 
progressively fewer planning decisions. The ultimate extension in this direction 
is of course for SPADE to request no guidance at all from the user. The user 
would supply the problem description; SPADE would provide the solution 

ZTJT\ ? ne T 61 aSPGCt ° f thiS approach t0 autonati c Programming is 
methodological: the SPADE series of systems provides an implementation strategy 
based on incremental simulation [Woods & Makhoul 1973]. 

Automatic programming is an extension of SPADE in a direction in which 
the user is pushed toward the higher level planning decisions, whereas the system 
performs more of the lower level choices. Exploration in the opposite direction 

that t S h/n°, S Hi ble; /? the 6Xtreme thlS am ° UntS t0 Pr ° t0C01 <"">ly"s- Suppose 
that the problem solving of a SPADE user is running far ahead of the system- the 

user may wish to type in code directly, rather than laboriously detailing the 

intermediate steps of the plan. The systems Job then becomes linking the low 

level event into a higher level planning structure. If every event typed by Z 

user were at this code level, SPADE would superficially be serving as a 

r\ conventional editing environment. The difference would lie in the assistance 
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ITcfllPAZAT, 9 TTT d f bU99in9, IdeaUy ' SPADE W ° Uld haV6 a ffl0dule <^ich 
we call PAZATil, for Protocol AnalZer based on an ATN) for inferring the user's 

versio^of the SpThp T imUCit ' ^ " lllust "tes "ow a hypothetical 
Znntnr , ♦ < ^"^ &[igmGnted * PAZA ™. could significantly reduce the 

amount of interaction required to articulate the planning knowledge \s well as 

00* a/ th ' ZJ? f SySt6n - CMiUer * G ° ldSteln 197 ^ takes a -r. careful 
pre^narr d es^ CUlti6S *>* »' """ ""^ ™' '-• a » d — ts a 

ThP pnHtf 113 ! a PPl icati °" 1« to prescribe improved programming methodology. 

stucture^f!! P M 6 emb ° dleS DiJkStra ' s Philosophy of programming in a 

HHh Moreover, it represents a more detailed study of planning 

interacMr 9 ^ niQUeS *" h " PreVi ° USly bee " attera P ted - " indict., Z 
Dlannfnn th r'n "" Str ° n9ly enC ° Ura96 coh ^^y structured articulate 
Planning. The underlying theory provides an analysis of the nature and origin of 

arise f^oTi, ^/m *V* ° f ^ "" ^ aV ° ided by lmpr ° Ved desi ^ and ""ion 
choiL. T JUStifiable heuristic choices. The occurrence of such uncertain 
choices however, can be recorded, leading to bookkeeping and diagnostic 

be a vn a nH /? " th ° S6 ^^ f ° r ™*' B ° tter **•«*"■ advice-- going 

beyond caveats for potential difficulties - must await the incorporation of PATO 
(and to some extent PAZATN) into SPADE. 

h*^ This i reP ° rt haS presented a un ified theory of planning and debugging 
based on a linguistic analogy. The design of an interactive programming 
environment has also been described. The objectives for this programing 

hi rTbut* T DE ' arS ^^ " SGrVe ' n0t ° nly " 3 PraCtiCal ^Plication oTthe 
theory, but also as an experimental crucible for testing claims of the theory. 

nf .. We ex P ect that experimentation with SPADE will yield the following kinds 
of information: (a) AI evidence regarding the heuristic adequacy of the planning 
taxonomy and grammar; (b) psychological evidence regarding the utility of the 
grammatical formalism as a modeling tool, for characterizing varying skill 
levels, in terms of which subsets of the grammar are used successfully and 
unsuccessfully; (c) computer science evidence regarding the efficacy of 
alternative documentation standards and design methodologies; and (d) 
Pedagogical evidence regarding the value for a learner of programming in this 
type of articulate environment. 
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Figure 26. A Scenario I l lustrating SPADE Augmented by PAZATN 



la. 



lb, 



W \m e p "Sif 1Vin ? f ° r 3 WISHINGWELL ' You »- P^ding subgoals are ROOF, 

POLE, WELL, and the interfaces. What now? 
>SQUARE 



Here the user types in an event at level of the actual code. The proper 

SMArViI nt \ t , heUSer U sol9t *' *° r WLf using an IDENTIFICATION plan. 
SQUARE is presumably in the user-defined answer library. 

2a. OK. I am assuming that WELL has been solved by IDENTIFYing it with the 

previously solved SQUARE procedure. What now? 
2b. >FORWARD TOO 

Again, the user has typed in a very low-level event which requires careful 

\ylV£?it ,1°*' J h€re ° re ° mmber °f ™ ct <>r commands which might be expected 
*y"t*eucally. For example, this could be the interface between the WELL and the 

Zuld betZVn lf the J mRE USed '" '*• »"<< " of sue 100. then FORWARD 100 
vector Lilt ,'\ lS °' ° preparator y r ot°"on would have been needed. The 
vector might also be a side of the TRIANGLE for the ROOF. However, if TRIANGLE 

solltiZ l n rn ll, anSW .l r libr0ry ' ^ ift * nti f ic °"on would be expected, not a new 
solution. Probably, this vector accomplishes the next main step in PATN's 
default solution order: POLE. However, PAZATN can employ a demon to postpone a 
final commitment until further evidence arrives. ' 

3a. OK. Vlhat now? 
3b, >TRI ANGLE 

4(l ' 0K t*!J?.V S R00F h0S bee " S ° lVed by ID ^IFICATION with the existing 

TRIANGLE. So the FORWARD 100 must be the POLE. Your only remaining 
subgoals are the interfaces. Vhich interface would you like to solve* 



fLtr tZl S feW USer tyPe - Us have been re ^ ired in this dialogue ~ 

almost coLZZ l \ COnVenti Z l G0 < 9 " yet Ue SOlUtio " '" «»• WSHIMGUELL is 
TtZl 11 " !"„ "° reouer ' the ****«■ *« ^Serred not only the code, but a 
rather thorough description of the user's plan as well. This economy of 
interaction would be achievable by the combination of SPADE, PATN and PAZATN 
enabUng the user to focus on the few critical planning choices that tor, o, less 
force the remainder of the solution. 
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7. Motes 

1. While there is some overlap, our objectives for SPADE differ in this 

^i^lma?;;: 6 !^ 6 ^^ ! f ° S : W ° rkin9 t0 C ° nStrUCt ^raJ^ZVeluTs 
LTeitelman 1970,1974; Hewitt & Smith 1975; Rich & Shrobe 1975]. It is too early 

however, for a detailed comparison of either goals or methods. 



Im\ n,*l\ \ " ° f the L09 ° 9raphics world CPa P ert 1971a 'b; 1973] are: 

n«!«fhi \* ^ environnent in which multiple problem descriptions are 

possible, ranging from Euclidean geometry to Cartesian geometry; (b) the 
possible programs range over a wide spectrum of complexity; and (c) there is 
Okum e u n rai e 973 ] CUnentati ° n °" ^ Perf ° rmanCe ln this ™ W- Goldstein 1973; 



/-s 



of thp * h '. ta sk domains are natural candidates for testing the generality 

p h t ! h6 °T The bl0Cks World ls a b en<*^k AI domain which provides a 
td *l * WhlCh t0 meaSUre the Pr ° 9reSS 0f our a PP roach - The set theory 
ThI , V V ^ tUeS ° f b ° th lntrinSiC interest and straightforward semantics. 
The creation of programs embodying concrete realizations of set theoretic 
constructs is a standard programming task. Similar remarks are appropriate for 

Ttltt^ , Programming an elementary calculator, such as to perform routine 
statistical analyses. 

4. In [Goldstein & Miller 1976a] we presented a scenario for a 
programming tutor called Sherlock. One extension of the SPADE system presented 
here is toward such mixed-initiative AI based personal learning environments. At 

er S n ^ Ume ' th K e SPADE st * le °f interaction suggests a more structured 
' X ™ ,i8 aPI T 0ach - Whether the additional structure is desirable for some (or 
most) students is an empirical question to be addressed in future research. 

5. In [Miller & Goldstein 1976b] we presented a different version (Gl) of 
the planning taxonomy and grammar, in the context of parsing a student protocol. 

di SC n ea p S r S TK° r aba " d0ning that version in ^vor of the current one should be 
discussed. The earlier taxonomy was based on examining the directions from which 

to dZin C ° Uld ° btain 9Uidance: l00kin 9 upward to general principles, downward 
J 1 SP " in , C heur i^ics, forward to anticipated needs, and backwards to 

Inliti ^ S ° ^ *' The CUrrent taX ° n0my deriV6S from examining the 

rlT S o C r deSCrlPtl ° n ° f the CUrrent <> r ° ble *- The former taxonomy emphasized the 
till s ° t f h : Xperira H e " tat i ion and «"« of past problems; whereas the current one 

IdHr!«oH t? ' S ° me ° f WhlCh UUCh 3S ex P e ^ntation) remain to be 

addressed. It remains true that decomposition techniques can vary along 
dimensions of domain specificity and generality. However, in some cases we found 
the earlier taxonomy to be problematic. As we began to incorporate semantic and 
pragmatic constraints on the grammar (see [Goldstein & Miller 1976b]), it became 
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^ of domain rt ? ,*° "**"** * f ° rml ^"notion between certain oxamples 

of domain dependent and evolutionary plans. There is of course a trade-off in 

semantT ed9e t0 thG SyntaCtiC rUl6S ' as W- t0 ■"i»»i»» it to 

claim tn a °t r , P H ra9ni C C ° nStralntS °" their ^Plication. In order to justify a 

Previous o ne w. CUrr iH t "V™ ° f the taX ° n ° my tS m ° re P^simonious than the 
previous one, we would need to carefully identify the corpus of data. While we 

this belief' 6V ! that the CUrPent V6rSi0n iS m ° re ele9ant ' the pounds for 

sSinp ! intuitive. In subsequent research we intend to employ the 

t«vn! T * "u 3 " 6Xperiraental vehicle ""• contrasting alternative planning 
taxonomies and their corresponding grammars. P 9 

to .it h!' J" 16 f ta ' ement that there is a "re set of planning techniques common 
to all domains is Justified by examining the formal basis for the taxonomy. On 

stLLT Z T r bUm deSCriptions are represented as predicate calculus 

statZnt , th3t S ° 1Uti0n Ca " Pr ° Ceed by: (1 > identifying the 

statement as one for which a solution procedure is known to exist; (2) 
decomposing the problem into subproblems on the basis of the top level logistic 
ZZV° r : uV 3) reforraulatin 9 the Problem description such as by theorem 
Proving techniques. That is, domain independence of the core set of planning 
technxques holds, on a priori grounds, to the same extent that problems in the 
domain are describable using predicate calculus problem descriptions 
np ., . 0f " U !" Se this ar 3«°«nt depends on the efficacy of the first order 
^ Predicate calculus as a problem description language. While we are not prepared 

sL^in *h thi \ h f re ' " iS Clear that fe calculus certainly has had some 
success in the past (e.g. in mathematics) and hence is an obvious candidate. Its 

LTr^V^Tl* deficiencies ' such as non-directed inferencing, are discussed 

oraani^H h , I** 19?6bh "*'" "* define a P^^ural problem solver 

organized around logical operators. It is also important to recognize that we 
are not arguing for uniform (e.g., resoiution-based) theorem prover style 
programming techniques. y B 

palprm M °reover extensions of the predicate calculus, such as higher-order 
calculi, do not obviate the need for basic problem solving techniques for dealing 
with conjunction, disjunction, negation, and quantification. 

nrnhl 7 ' Thi * view of Plying is a simplification. It asserts that the 

pn»™!Y S ana y26d ln a t0P d ° Wn faShl0n - ° f C0Urse « the Pr^lem solver can 
engage in exploration and experimentation; or can identify a subgoal without 

1ZZ\ Z U " derStandlng ° f the 0Vera11 plan - ™* dynamics of exploration 
are not formalized by this grammar. 

8. Our use of a context free grammar for problem solving closelv 
resembles D. Rumelharfs [1975] work on story grammars. It should be interesting 

tO See to what ovfonf Am. -*-.*--.•. j .._ ^» ** 



♦ « «.~~ + ~ i_ ^ * u oiiuujlu ue interesting 

suoerfici.nv ^h^ ° Ur reSP6Ctlve theories, designed to account for 

it be uslf, f VGry dl / f6rent Phen ° mena ' C ° ntlnUe t0 devel °P ^ Parallel. Would 
it be useful, for instance, to define a set of summarization rules (such as those 
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employed by Rumelhart) to describe the planning process? One possible set of 
Plan summarization rules would focus on the SOLVE nodes, suppressing printout for 

subnL/n ^r^ Conceivabl y' this c °«l<» be useful in highlighting the 

subprocedure organization. 

9. The rules of the grammar are written using the following syntax: 



disjunction: 



"a I b" is read as, "a or b n ; 



ordered conjunction: "a + b" is read as, -a and b", 

where the order is significant; 

unordered conjunction: "a & b" is read as, "a and b\ 

where the order is insignificant; 

optionality: » [a] - is read as> „ a is optional „. 

iteration: »< a >*« u read as> 

"a repeated 1 or more times"; 

lexical category: a lower case English phrase enclosed in 

quotation marks (e.g., "number") 
/*\ describes a lexical item which is not 

further expanded in the grammar. 

10. The & operator is used, because the GET and USE can occur in any 
order as long as they both precede execution of the procedure being defined. 

11. While the Mycroft system designed by Goldstein was potentially 
capable of semantic annotation, it lacked a clear formalization of the range of 
possible planning choices a program designer could make, and a description of 
possible errors in terms of these design decisions. The grammar we present here 
is intended to address these limitations. 

12. The interactions presented here are hypothetical dialogues with a 
system which has not been implemented. Although a crude preliminary 
implementation (SPADE-00) has recently begun, it is currently lacking several 
essential features. 

One deficiency of SPADE-00 is that it has not been interfaced with LLOGO 

J"""" et ' 3l - " 74]; hence " ls not P°"ible to actually execute the 
resulting programs. Another deficiency is that the RAID features described in a 
later section have not yet been coded. 

rs *~, J*? T P ° Se ° f presentin 9 hypothetical dialogues, rather than actual 

r^ transcripts, is to enable the reader to focus on the content, without being 
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RealVTwho h^ detailS C ° ncernin9 the inadequacies of the implementation. 
lllTtZ t , 9CCeSS t0 thS laborator y' s timesharing system are nonetheless 

in v Z " WUh ° Ur tPial V6rSl0nS ° f SPADE as follows ' After logging 

i.;,i„n ««^ Cr> ' :NSPADE WiU 9enerally be a neWer ' hi ^ experimental 
by !sPADE. Wm ^ ^ ° lder VerSi ° n ' in CaSe ° f diS3Str0US functioning 

choice" s S ty A l D e E "°° SlmpUfieS the int eraction by employing a "menu" or "multiple 

WHAT WOULD YOU LIKE TO DO? 

=A — IDENTIFY 

=B — DECOMPOSE 

=C — REFORMULATE 

>=a 

Certain operations, such as the LATER capability, are implemented as special 
escape commands," in order to reduce ambiguity and simplify parsing. For 
example: 

>later 

I DON'T UNDERSTAND: LATER. 

>@later 

POLE POSTPONED. 

TrllJliVV' th6 T tem 1S self - docurae "ting, and is gradually becoming 

iiie^\rsprDE @ u MiT. A r 99estions and bug messa9es may be sent via the — 

13 The question arises as to whether the bug taxonomy is exhaustive when 
circumlocutions and slips of the tongue are also included. In a trivial sense 
the answer is "yes" because the latter class is open-ended by definition. In a 
deeper sense, the answer may also be "yes" in that no bugs need ever be assigned 
to this category which violate our intuitive requirement that the underlying plan 
prove affeCted ' ThiS iS a h ™°thesis which we tentatively accept but cannot 

rlat ..« M * T ° aV0id P oss ible confusion, it should be stressed that our bug 
classification does not correspond to the usual terminology of programming lore. 
While there is a slight analogy, it may be misleading. That is, "syntactic 
Planning bugs" does not refer to the syntax of the programming language; it 
refers to the hierarchical structure of the process of constructing programs. 
Similar remarks are in order for semantic and pragmatic planning bugs. For 
brevity we may use the shorter phrases, e.g., "syntactic bug," to refer to a 

^ Trlllr P n lannlng 4 bU9 ' For the ra °st Part, we are not concerned here with syntax 
r^ errors (or "semantic errors") in the usual sense. 
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if the c 1 o m ™tT Ural ° bJeCtl ° n iS that this P^ticular bug could be eliminated 
if the computing environment were modified so as to automatically load 

wHT2:t\![ llai Wh6n "^^ ^ C ° mPletely a9ree ' Ind6ed ' " ill-trl?., the 
point that the grammar illuminates the design of improved computing environments. 

It in no way alters the observation that, given any particular computing 

mult ZZl* T^ SyntaCUC Constraints on th * ^ructure of programming plans 
must be adhered to, nor that violation of these constraints constitutes one type 
or error. ^ K 

«inmi v r 16 ' ° f /° UrSe ' the issue arises as t0 whet "er the human problem solver is 

fn™ 1*7, J PaPt ° f a kn0Wn rUl6 ' ° r iS Unaware of the rule in the proper 
tl?i .? ! t0 3 S6t ° f difficult P robleB * ^ Protocol analysis surrounding 

the hypothesizing of the grammar underlying a given individual's problem solving. 
This topic is pursued in [Miller & Goldstein 1976b, d]. 

wh„n < 1? \ Th , 6 0Ccurrence of two consecutive calls to a given primitive is odd 
T«? I ItlL lnVOCation » perha P s with «l*ered input, will suffice. In Logo, two 
adjacent PENUP commands, or two adjacent FORWARD instructions would be considered 
rational form violations. 

18. This wishingwell program employs what Goldstein [1974] termed an 
insertion plan." The TREE shown here is inefficient in that it achieves state 
transparency via retracing the TRUNK. There is also a tradeoff in the WELL 
between modularity and efficiency. The use of the insertion plan to avoid 
retracing on the top side of the WELL results in less modular code. These points 
are noted only to avoid misunderstanding -- they have no bearing on the thrust of 
the example. 

n„h, "; Viewln « debugging from the vantage point of this taxonomy sheds some 
light on the issue of the pedagogical value of various kinds of bugs. Our 
current understanding of the first three (and to some extent the fourth) 
categories of bugs suggests that encounters with such bugs may be instructive in 
teaching planning as well as debugging. However, -slips of the tongue- at best 
provide some exercise in bug localization. Hence, a -forgiving" system that 
minimizes the penalties for such low level bugs is probably pedagogically sound. 

^m r'rT,* thlS PhUosophy is the Interl i*P W/M (Do Uhat I Mean) 

facility [Teitelman 1970,1974]. (By contrast, our effort to make more of the 
Plan explicit might be called SUM, i.e., Say What I Heanl) 

h d k < 2 °; l f r d6f lne a C ° nt6Xt free 9ramnar for basing, then this error in 
debugging technique can be classified. For example, if the rule of the debugging 
grammar for fixing slips of the tongue is: 



^ REPAIR 



■> [UNDO] + REDO 
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context ^r " lter " atiVe ^V de " U3gln9 "° Uld be t0 ="aracterize planning „ , 
context free grammar, while debugging is described as a transformation,,? 
component that maps derivation trees to derivation trees. nllZuU be 

resolution of this issue goes beyond the current paper. 

which would hVi e o r To b ^ e " y / ntr ; oduce * ^ule we are designing called PAZATN 
narTinT P - alleviate this difficulty. PAZATN would be capable of 

parsvng programming protocols, inferring - from a combination of synthetic 
expectations and analytic evidence - which plans had been used synthetic 

bv doina 2 L\!, Un l larnenta / hypothesis of the L °9° Project is that children learn 
the SPADE edit" 1 '; 7 T "*" "" *" ^ ° f ° Ur PUrp ° S6S in ^le-nting 
merits of spadf T*™ ^ hypothesis by experimenting with the relative 

merits of SPADE versus the traditional Logo programming environment. In SPADE 

l\na a /rf ^^ *° * ^^^ W,ith « r thiS helps stud ^ " «"" 

seen Our T" 9 C ° nC6PtS "^ QUiC,tly " ° r hinders thera " remain, to be 

• r t ° njeC r " th3t deSpite the extra interaction demanded, students 

^ help in l..rni n n e - articula t° about their problem solving a significant 

Sickly arnln9 ' " meaSUred by an abillty *• "Iv. harder problems more 
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